This question and answer file contains APPN-related questions from APPN vendors and customers, and the answers provided by APPN architects and product designers, where appropriate. These Q&As deal with the following subjects, in that order, over the period Aug. '93 - Feb. '94. Subject: Explicit/Implicit Locates Subject: Border Node & Dependent LUs Subject: Border Node Subject: APPN+/HPR Subject: Sense Data Subject: Border Node Subject: ATM Subject: APPN XID and Bind Pacing Subject: APPN Border Node Subject: APPN Subnet Configuration Subject: AS/400 - LEN Bind Requests Subject: AS/400 - Non-activation XID3 request Subject: APPN CP - CP Sessions Subject: Border Node Capabilities - Extended and Peripheral Subject: Activation XID Exchange Subject: SSCP Take-Over with LEN nodes in Network Subject: AS/400 - Secondary Initiated XID3 Subject: Adaptive Pacing Subject: IBM-supported SAP Addresses ----- APPNQA FORUM appended at 18:28:03 on 93/08/16 GMT (by HEFEL at RALVM6) -- Subject: Explicit/Implicit Locates Date: 8/06/93 Owner: Jim Cobban Compuserve? N Question: In a Locate response, as documented in SNA Formats, there is a bit in the FIND control vector which, if zero, says this is either an explicit or a partial match. The Network Node, in performing its search, first looks at explicit matches and then if it can't find one, looks for a partial match. But how does it know from this response? The generic names are always described as ending with an asterisk, but the directory name control vector in this response carries a symbol using character set 1134, which does not include an asterisk. So how do we distinguish between an explicit and a partial match in a Locate response? Answer: The answer to your question is - You can't distinguish whether a match is for an explicit entry or a partially specified entry. Partially defined entries are always considered to be explicit. The good news is that you don't need to be able to tell the difference. You're right. Partially specified names end in an asterisk. However, they can only be used in directories. They cannot be used in a Directory Entry (x'3D') control vector or a Search Argument Directory Entry (x'82') Find control vector. Therefore, they cannot be used in Find, Found, Register, or Delete. (This means that wildcard and partially specified directory entries can only be home (NOF-defined) entries.) The Directory Entry control vector in the response (a Found Resource (x'12CB') GDS Variable) is the same as the Search Argument Directory Entry in the request (a Find Resource (x'12CA') GDS Variable) whether the resource was defined explicitly or not. The only thing the originating Network Node can tell is if the directory entry for the located resource is a wildcard entry. This is done using the bit you mentioned in the Command Parameters (x'80') Found control vector (not the FIND control vector). Note that this has some implications for how resources are defined in your network. A Network Node can distinguish between resources that are defined explicitly and resources that are partially defined in its own directory, but the originating Network Node can't tell the difference between an explicit match from one node and a partial match from another. Partially defined entries always appear as explicit outside the node where they are defined. Care must be taken when assigning resource names to ensure that a partially specified name will not match ANY resources defined on any other node in the network (with the same netid). The originating Network Node can tell if a response was due to a wildcard directory entry, so it won't get conflicting responses when a resource is found explicitly and due to the wildcard. However, a wildcard may only exist at one node in the network. Security(Public/Private): Architect: Raplh Case Comments: ----- APPNQA FORUM appended at 21:42:26 on 93/08/22 GMT (by HEFEL at RALVM6) -- Subject: Border Node & Dependent LUs Ref: Append at 18:28:03 on 93/08/16 GMT (by HEFEL at RALVM6) Date: July 23, 1993 Owner: Rainer Foeppl Compuserve? Y Question: Let's take the following configuration: AS/400(Net1)---APPN---S/390(Net2) One question that occurs immediatley is What happens to dependent LU's which want to access an application on the host? If a AS400 is a LEN-Node there is no problem, but if they are a Network-Node ? Thanks for your help and have a nice weekend Rainer Answer: Here is how the AS400 works today. The dependent LUs come across the link from an AS/400(NN/EN) to a LEN S/390 where the AS/400 looks like a PU2.0. We also run 2.1 across that same link for APPC connections so that the one link supports 2.0 and 2.1. Once the link switches to NN-NN, we should continue to work as long as VTAM continues to send down the ACTPUs/ACTLUs that they do today for attached PU2.0s. Our dependent attachment only works if the AS/400 is boundary attached to the S/390 or SNA/PassThrough is used to get a dependent through a string of AS/400s into a subarea. Either way, the dependents still come into the S/390. Of course non-boundary attached AS/400 dependents that do not have an AS/400 only path into the subarea can not support dependent LUs. Security(Public/Private): Public Architect: Doyle Horne Comments: ----- APPNQA FORUM appended at 14:17:00 on 93/08/24 GMT (by HEFEL at RALVM6) -- Subject: Border Node Ref: Append at 21:42:26 on 93/08/22 GMT (by HEFEL at RALVM6) Date: 08/22/93 Owner: Mark Seery Compuserve? Y Question: In the AS/400 implementation of APPN, two Network Nodes (NN) can not communicate directly, they must go through a border node if they are in different networks. 1) Is this still the case? 2) WIll this be the case for other implementations of APPN? 3) If this is changing, when will it take affect Answer: You are correct in saying that two NNs in different topology subnets should communicate through a border node (BN). The BN preserves topology isolation between subnets. This is a desirable characteristic which prevents nodes in one subnet from knowing the topology of an adjacent subnet (good from a security perspective) and prevents topology updates from leaving a local subnet (good from a performance perspective). Base APPN network nodes with different network IDs can not bring up links with each other. In the future I do not expect that architecture will change to allow CP-CP sessions between NNs with different network identifiers unless one of the nodes was a BN. This enforces a topology boundary based on network ID. In the future, different networks will probably still require BNs for APPN connectivity. Security(Public/Private): Public Architect: Doyle Horne Comments: ----- APPNQA FORUM appended at 17:41:55 on 93/08/24 GMT (by HEFEL at RALVM6) -- ..... APPNQA FORUM modified at 15:15:12 on 93/09/01 GMT (by HEFEL at RALVM6) .. Subject: APPN+/HPR Ref: Append at 21:42:26 on 93/08/22 GMT (by HEFEL at RALVM6) Date: 23 August 93, 13:02:05 EDT From: Marcia Peters 8-444-4380 MPETERS at RALVM6 To: HEFEL Date: 08/22/93 Owner: Mark Seery Compuserve? Y Question: Can anyone tell me if it is possible to purchase documentation from IBM on any of the following subjects: 1) APPN+ 2) APPN++ 3) Broadband Network Services architecture 4) HPR 5) ANR Answer: First let me be clear about terminology. Some of your terms are synonyms. In March 1992 IBM announced a planned migration path: SNA to LEN to APPN to APPN+ to APPN++. The latter two terms were "place holders". We now have an official name for APPN+ and that is High Performance Routing (HPR). The place holder APPN++ stood for Gigabit Networks and we now have an official name for this technology: Broadband Network Services. BNS is a subnetworking technology (the red layer in the networking blueprint) and, as such, does not replace APPN or HPR or TCP/IP or NetBIOS or IPX or any other transport/routing protocol (the green layers in the blueprint). Because all these protocols use BNS as a link, BNS should not be considered an SNA technology at all but a new open subnetwork for both data and isochronous (voice/data/image) traffic at high speeds, based on standard ATM cells, plus BNS which defines the internode control point flows currently absent from the ATM standards. 1) and 4) No. Documents available today include a white paper "Preview of APPN High Performance Routing" by Gray and Peters, and an academic paper "Comparison of Congestion Control in TCP Slow-Start and APPN+" by Chang, Gray, and Huynh (no charge). An overview of HPR and an introduction to HPR line flows were presented at the APPN Implementers' Workshop and are available (no charge). We will publish a draft specification for HPR in the 3rd quarter of 1993 (available via the APPN Implementers' Workshop at no charge). Licensees of IBM's Network Node source code toolkit will receive HPR in the next release: availability is expected to be approximately 1Q94. The HPR upgrade is included in the price of the source code (i.e. no additional charge). 2) and 3) A white paper on BNS is in draft. It should be ready sometime next week, around Sept. 1. A large number -- 40-50 -- of IBM's contributions to the ATM Forum are based on BNS. IBM has said we intend for BNS to be open. Beyond the ATM Forum submissions, the schedule and additional steps IBM plans to take in opening BNS have not yet been announced. 5) ANR = Automatic Network Routing. ANR is deterministic source-routing technique that both HPR and BNS use for routing variable-length data packets. Researchers at IBM's T.J. Watson Research Center published papers describing some of the ANR functions in the 1989-1990 timeframe. ANR is also briefly described in the above-mentioned documents and will be more fully described in the spec. Security(Public/Private): Public Architect: Marcia Peters Comments: ----- APPNQA FORUM appended at 20:48:21 on 93/08/25 GMT (by HEFEL at RALVM6) -- ..... APPNQA FORUM modified at 15:13:46 on 93/09/01 GMT (by HEFEL at RALVM6) .. Subject: Sense Data Ref: Append at 17:41:55 on 93/08/24 GMT (by HEFEL at RALVM6) Date: 08/25/93 Owner: Bruce Dean, Burt Gearhart Compuserve? N Question: One of our CompuServe customers pointed out a slight mismatch between the SNA Formats and the APPN Architecture REf description of sense data 0809-0039. I looked at them and they appear similar but not identical. Are they close enough, or is there really an error here? Please let me know if there's anything you'd like us to reply to him with. The sense information in Dr. Walkers "APPC Sense Data" document does not agree with the information in the APPN architecture -3 manual on Pages 5-27&5-132 for sense code 0809 0039. Answer: First off, I strongly recommend that you always consult the SNA Formats Manual (GA27-3136) whenever there is a question regarding the meaning or definition of a SNA format (this includes sense data). Any other publication may be correct at the point in time when it is written, but if changes are made to the format, they are not likely to be reflected in other manuals. As it turns out, Dr. Walkers document is word for word exactly the same description as presented in the SNA Formats Manual. I do not believe that the descriptions in APPN Reference and SNA Formats Manual/APPC Sense Data documents are incompatible. The descriptions in the APPN Reference manual concentrate on the conditions under which the value is sent. The SNA Formats Manual documents the same information in another manner. Generically, this sense data value is issued whenever the LU6.2 transaction to request and provide a CP Capabilities GDS variable does not take place as designed. This is most easily detected by looking for the CEB and CD bits are one mechanism to discover some transaction related problems. The APPN Arch. Reference document is a bit more general in that it tells implementers that this sense data value is also to be used when any other transaction related errors are discovered. In reality, the REQ_CP_CAP_TP issues some RECEIVE_AND_WAIT verbs, once everything is received it checks for a primary return code of DEALLOCATE_NORMAL and a verb count of 2. If either one is not true, it issues the 0809 0039 sense data value. Bottom line is that sense data definitions are often not as descriptive as one would like. Architects need to play a tough trade off between being specific enough to describe the problem, but general enough so that we do not have a great number of values that are very similar. Hope this helps. Security(Public/Private): Architect: Dave Bryant Comments: ----- APPNQA FORUM appended at 13:02:47 on 93/08/26 GMT (by HEFEL at RALVM6) -- Question: Subj: APPN Border nodes Section: APPN Architect Only From: Mark Seery 76570,2055 # 9745, * No Replies * To: APPC Market Enablement 76711,370 Date: 25-Aug-93 00:47 Doyle, Thank you for you thoughtful reply. I can not argue with you that NetID based topology boundaries are not good from a performance or security perspective. But there is an obvious lack of configurability/network awareness when compared to TCP/IP based networks who with the exception of router filtering etc. have access to nodes on many subnets. Is there any concern from IBM that this will be a big issue with some users. And did I read somewhere about an extended border node functionality that gets around this problem - and if it does, will extended border nodes be available on all platforms. Actually will normal border nodes be available on all APPN platforms, or just well positioned ones such as VTAM, OS/2, 3172 and 6611 and perhaps RS/6000. Thanks, Mark. P.S. This is a great service, I hope other IBM departments will feel inclined to offer the same thing. Answer: The term "extended border node" applies to a border node (BN) that can be used to establish connection between LUs separated by a series of topology subnets. It does not imply Network awareness of topologies in more than a local subnet. Instead the BN functions similar to an IP gateway in that the search (or BIND) is sent to the BN and the BN handles things from there. The origin CP does not know where the destination resource really is or the route to get there. If network awareness is needed between a group of network nodes, they can be given the same network ID. If network awareness is not desired, the nodes can be separated by a BN or given different network IDs. This seems to be a good working model for most of our customers. If it turns out that there is a stronger case for additional network awareness than we currently envision, we can consider architecting a solution to provide that additional awareness. It is not expected that the BN tower will be implemented on all (or even most) APPN platforms. Security(Public/Private): Architect: Doyle Horne Comments: ----- APPNQA FORUM appended at 14:56:13 on 93/09/01 GMT (by HEFEL at RALVM6) -- Subject: ATM Section: APPN Architect Only Date: 08/25/93 Owner: Mark Seery Compuserve? Y Question: (NOTE: Answer embedded in Question, prefixed by '>' tag) Marcia, Thank you for your lengthy response, it is much appreciated. I have long read your quoted comments in the trade press and am pleased to have made electronic contact with you. > Hi Mark. > Thanks, you wouldn't believe what they choose to quote and not quote. > Sometimes out of a 4 hour meeting the press will pick one sentence > unrelated to the primary topics of conversation. Still, I enjoy > working with the press (usually) because it's often the most direct > way to get word out to customers. You said BNS is based on standard ATM cells plus internode control point flows currently absent from ATM strategies 1) What is meant by "based on ATM cells"? Does mean based on the "spirit" of ATM cells or based on the ATM cell format? >>Mark this is Jerry Marin. I'm the manager of the teams working on Broadband Network Services. I've been asked to help with these answers for the BNS related questions and will use >> to denote my input. >> BNS can operate over standard ATM lines (in which case everything is sent in standard ATM cells) and it can also operate over links supporting variable length packets. When supporting variable length packets (we call this packet transfer mode or PTM), ATM cells can STILL be transferred (mixed with variable length packets) and will STILL be in standard ATM cell format. +++2) When you talk about internode flows currently absent from ATM standards are you referring to NNI specifications or more than this.? >> This is tough to handle in a brief answer, but I'll try. BNS fully supports the existing ATM standards including cell formats, selective use of the AALs (depending on the service being offerred), and signaling at the edges of the network based on the Q.93B extensions adopted by the ATM Forum. Inside the network there are many "how to's" that have not been defined by standards or the ATM Forum. For example, how does the network find an optimal route for a requested quality of service? How does the network support multicast (1->n) routing? How does the network manage its bandwidth and control congestion internally? How does the network accomodate access to foreign protocols? (The latter implies much more than simply encapsulation and segmentation using the AALs.) So far there are no NNI specifications related to these kinds of "how to" questions. A new subworking group started this summer at the ATM Forum to begin addressing at least some of them. IBM is fully participating in this subworking group. We will be contributing ideas based on what we've learned with BNS. We will support whatever comes out (over time) from the ATM Forum and standards groups. In the meantime our products will, of course, use BNS to complement existing ATM standards and implementors agreements. +++Will there be a way for me to purchase/obtain a copy of the BNS white paper when it becomes available on/around September 1? >>A softcopy will be posted to the APPN Architect Only section under the Library category in this forum once it is available. You said ANR = deterministic source-routing technique that both HPR and BNS use for routing variable length packets. 1) This sounds like the ANR described in the very good Red Book "High-Speed Networking Technology" GG24-3816-00. That book described ANR as it related to the PARIS project. > Yup. >>BNS actually offers several routing modes that are tailored to the protocols being routed. Thus, we would use label swap routing (works conceptually like APPN and IP in that packet labels are used to look up the next link in tables that must be built before packets are sent). This routing mode is also appropriate for Frame Relay, for example. For ATM cells we have ATM "routing mode" which is exactly ATM routing based on the VPI/VCI fields in the ATM cell. For any datagram traffic and for BNS control flows we would use ANR routing which, as I recall, is described in the Red Book. The advantage of ANR is that tables need not be built in intermediate nodes before information can be sent. This is extremely useful for the control flows that build tables dynamically, say, to support the other routing modes. My impression from the book was that ANR's benefits were obtained from a hardware implementation. Yet ANR is to be offered as a software implementation. initially. Is this the same ANR that was used in the PARIS project? > ANR was initially designed for a highspeed hardware implementation. > However, unlike ATM (which does indeed require new hardware), > excellent ANR implementations can also be done in software. The > cutover point at which a hardware implementation makes sense depends > on (a) the type of product (b) the intended link speed. We found that > ANR routing can realize a 3-10x speed improvement in APPN, as compared > with current APPN ISR (intermediate session routing) and and ANR > router can support a much larger number of intermediate sessions that > a standard APPN NN, due to savings of CPU cycles and storage (session > control blocks). >>HPR is fundamentally intended to be used in existing hardware; hence, the software implementation that Marcia describes. ANR will perform better with a hardware implementation as is being done in the newer products. The HPR implementation allows customers to get the benefits Marcia describes in their existing products through software upgrades. When customers are ready for robust multimedia support, for ATM, for highspeed links (say greater than T3), it will make sense for them to invest in the new hardware. +++2) ANR is used for variable length packets - yet ATM is a static sized cell. Will ATM cells be encapsulated in variable-le!ngth cells or converted to them or what? And what are the benefits? >>As noted earlier, ATM cells can be intermixed with variable length packets on BNS links that support variable length packets. (BNS can also work over links that support ATM cells only. Your question refers to the mixed case.) On such a "PTM" link, the header for our non-ATM packets includes the routing mode as the first three bits. Thus, there is a designation for ANR and another for label swap, etc., in the first three bits. For all routing modes except ATM routing mode, the packet is then decoded using a BNS PTM format that is not a standard (at least not yet) but will be open. When these first three bits designate "ATM routing mode," the packet is interpreted to be a standard ATM cell. Thus no cell format conversion is necessary. As you probably know, the first three bits of the ATM cell are defined as GFC bits at the ATM UNI. These bits are only interpreted at the access link and do not need to be preserved accross the network. Thus, cells can flow "natively" on PTM links inside the network with no need for the additional overhead of encapsulation. The principal advantage of this is that it offers users flexibility in introducing ATM into their networks without having to move all traffic in a subnet to ATM at once. This may result in significant bandwidth savings for some users. For example, if a particular user traffic stream is predominantly 64-byte packets, ATM would require each of these packets to be sent as two 53-byte cells with a resulting overhead of (10+32)/106 x 100 = 40 %. We think customers will benefit by the flexibility to interoperate fully with ATM while introducing ATM traffic into their backbone network under a migration strategy of their own devising. Any customers that wish to do so can certainly convert their network to ATM all in one step also. They do not have to user variable packet links inside a BNS network. Once again, thanks for your time. Regards, Mark. Security(Public/Private): Public Architect: Marcia Peters, Jerry Marin Comments: ----- APPNQA FORUM appended at 19:18:10 on 93/09/07 GMT (by HEFEL at RALVM6) -- Subject: APPN XID and Bind Pacing Ref: Append at 14:56:13 on 93/09/01 GMT (by HEFEL at RALVM6) Date: 08/25/93 Owner: Jim Cobban Compuserve? N Question: On page 6-17 of the APPN Architecture reference (4th edition, March 1993) it says: "Note: BINDs for both independent and dependent LU-LU sessions should be paced using the adaptive BIND pacing algorithm described in this section. However, some nodes not at current level of SNA may not pace dependent LU BINDs (while pacing independent LU BINDs). ... Dependent LU BINDs sent to and received from such nodes are not paced." On page 9-230 it is stated: Senders always indicate support for adaptive BIND pacing as senders and receivers. The Qualifier for Adaptive BIND Pacing Support indicator should be set to support "Both Dependent and Independent LU BINDs unless overridden to Independent LU BINDs Only by the Adjacent Node." In SNA Formats (GA27-3136-12) the Qualifier for Adaptive BIND Pacing Support indicator is described at the bit level. In particular the bit setting for "Independent LU BINDs only" notes that it is incompatible with the bit setting 00, which indicates unconditional support of both Independent and Dependent BIND pacing. This creates a number of contradictions: 1) A LEN EN implementation constructed to comply to the documentation at any level prior to this year will have set the Qualifier for Adaptive BIND Pacing Support indicator to zero, because it didn't know that such a field existed. That is true even though, as a pre-Version 2 implementation it is within its rights to NOT pace dependent LU BINDs. However a Version 2 implementation will interpret that setting as indicating support of both types of BINDs. 2) An implementation of APPN which conforms to version 1, and decides to not support pacing of dependent BINDs, cannot negotiate to an acceptable setting of the option with a node which sets, or defaults the option to zero. It seems that the only choice which an implementation which supports only Independent LU pacing has is to not handle Dependent LUs at all if the adjacent node signals "Both Dependent and Independent LU BINDs" even though the adjacent node is probably just back level, and would be perfectly happy to support Dependent LUs. Is there some way that I can recognize that the Qualifier for Adaptive BIND Pacing Support indicator is zero just because the node is back level and didn't know that the field existed? Answer: Jim, It was not "within the rights" of a pre-version 2 implementation to pace only independent binds. Implementations which did so were in error. The architecture update which introduced the Qualifier for Adaptive Bind Pacing was a circumvention for the products that were in error. These products were changed to set '11'b for the Qualifier, so that up-level nodes could negotiate to an acceptable setting of the option. You therefore should not have a concern with a down-level node (Qualifier setting='00'b) supporting BIND Pacing for independent LUs only. On the other hand, problems can arise between a down-level node (Qualifier setting='00'b) and a node which paces only independent BINDs (Qualifier setting='11'b). Dependent LU-LU sessions cannot be supported between two such nodes. So to answer your question: >Is there some way that I can recognize that the Qualifier for >Adaptive BIND Pacing Support indicator is zero just because the >node is back level and didn't know that the field existed? If the indicator is zero, you should assume BIND Pacing applies to both independent and dependent LUs. If only independent LU BINDs are paced, the indicator would be '11'b. Security(Public/Private): Architect: Tom Moore Comments: ----- APPNQA FORUM appended at 15:17:58 on 93/10/13 GMT (by HEFEL at RALVM6) -- Subject: APPN Border Node #29 Date: 09/02/93 Owner: Rainier Foeppl Compuserve? Yes Question: There are two types of border-nodes, the border-node and the extended border node. The extended border node can be used to connect chained APPN-Networks. Questions: 1.) What Products have the extended border-node implemented ? 2.) Can topology-updates cross networks that are connected by border-node or extended border-nodes ? Answer: 1) VTAM V4R2 is the only product which has announced extended BN 2) topology updates are not passed across topology subnet boundaries by border nodes. Security(Public/Private): Architect:Doyle Horne ----- APPNQA FORUM appended at 15:18:45 on 93/10/13 GMT (by HEFEL at RALVM6) -- Subject: APPN Subnet Configuration Date: 09/03/93 Owner: Rainer Foeppl Compuserve? Y Question: Assuming the following network: CNN: Composite Network Node (VTAM + NCP) NN : Network-Node EN : End-Node LEN: Low-Entry-Network Netid: Network-Identifier SNI: SNA Network Interconnect SNI: SNA Network Interconnect CNN ------------ SNI ----------- CNN (netid1) (netid2) | | LEN LEN | | | | EN----------NN------------NN----------NN NN (netid3) (netid4) (netid4) (netid5) (netid6) CNN-Nodes have VTAM 4.1 NN and EN have OS/400 (current Version) Question: Who can connect to who or what might be easier: Who can NOT connect to who ? Answer: It all depends on who is initiating the session to who. The following table can be used to document this. origin +--------+--------+--------+--------+--------+--------+--------+ | | netid1 | netid2 | netid3 | netid4 | netid5 | netid6 | d +--------+--------+--------+--------+--------+--------+--------+ e | netid1 | Y | Y | Y | N | Y | N | s +--------+--------+--------+--------+--------+--------+--------+ t | netid2 | Y | Y | Y | N | Y | N | i +--------+--------+--------+--------+--------+--------+--------+ n | netid3 | Y | Y | Y | N | Y | N | a +--------+--------+--------+--------+--------+--------+--------+ t | netid4 | Y | Y | Y | Y | Y | N | i +--------+--------+--------+--------+--------+--------+--------+ o | netid5 | Y | Y | Y | Y | Y | Y | n +--------+--------+--------+--------+--------+--------+--------+ | netid6 | Y | Y | Y | N | Y | Y | +--------+--------+--------+--------+--------+--------+--------+ What this shows is that resources in netid4 can only initiate a session to resources in netid5, and resources in netid6 can only initiate sessions to resources in netid5. Resources in any other network can initiate a session to all other networks, including those in netid5 or netid6. This has to do with the way R1BNs determine when to forward forward and accept searches across network boundaries. A R1BN will only forward a Locate across a network boundary when the NETID of the adjacent network matches that of the destination resource. Likewise, a R1BN will only accept a Locate across a network boundary when the NETID of the destination resource matches its NETID. This restriction is only applicable when a R1BN receives a search from an NN with a different NETID. It does not apply to LEN connections. That is why a resource in netid1 can initiate a session to a resource in netid4, but a resource in netid4 cannot initiate a session to one in netid1. One thing to note: I am assuming that netid4, etc., are simply placeholders for the real names which we do not know. As such, there is no way to determine if the NN in netid4 or the NN in netid5 would be the one to assume the R1BN role. One other thing. If you upgrade the connections between the NNs and the CNNs from LEN to APPN, then the networks connecting across the SNI backbone will no longer be able to communicate. That is, until R2BN comes along in V4R2. Security(Public/Private): Public Architect: Roy Brabson Comments: ----- APPNQA FORUM appended at 12:35:47 on 93/10/27 GMT (by HEFEL at RALVM6) -- Subject: AS/400 - LEN Bind Requests Question: Our product is a LEN. In the BIND request, we select #INTER as mode, and control vector 2C is added with zero length COS name ( the priority bits are set to high priority). We have encountered the following problems: 1) AS400 rejects the above BIND request. 3174, OS/2 accept it. 2) AS400 rejects BIND with MODE definition and without vector 2C. 3) When a LEN sends BINDs through a NN, the LUs are registered dynamically. With the AS400, unless we register the LUs, session can not be established between two LENs. The AS400 software version is 2.0. Answer: 1) You're correct although the AS400 will soon be modified to accept a COS/TPF CV (X'2C') with a zero length COS name, and map it to #CONNECT which is the default COS. 2) If you are sending #INTER as mode name w/BIND and not including the 2C CV, the AS400 will not reject the bind request. Are you sure you have your facts straight on this? It should be mapping the mode to the correct COS for the LEN node. If you are including an RSCV on your BIND, the AS/400 as well as all APPN products, expects there to be a COS with it. If a COS is not included the BIND is rejected with a "SNSNCSBN BIT(32) CONSTANT('086C2C00'X)" (COS/TPF not on BIND). 3) According to the SNA APPN Architecture Reference (SC30-3422-03) the behavior indicated in the second sentence is correct. Page 1-6 describes the LEN functions which the AS/400 (as a NN) is implementing. For example shown, LEN_1 has a link (Link_1) to Network Node A (NNA) and, LEN_2 has a link (Link_2) to Network Node B (NNB) with LU's at the LEN's. LEN_1 --- Link_1 --- NNA..............NNB --- Link_2 --- LEN_2 (LU_1.1) (LU_2.1) (LU_1.2) (LU_2.2) According to the architecture: LEN_1 's LU's, CP name and Link_1 must be defined at NNA. LEN_2 's LU's, CP name and Link_2 must be defined at NNB. If LEN_1 wants to access a remote LU (i.e., LU_2.1), LEN_1 should assume LU_2.1 is attached to NNA. LEN_1 sends a "blind bind" to NNA and NNA takes care of setting up the session to NNB and the remote LU. NOTE: AS/400 will cache an LU name equal to the CP name of an attached LEN node so that at least the CP name does not have to be sysdef'ed at the NNS (and that is usually good enough for most PC LEN nodes). Architect: Candace Elder APPN Architecture Mark Cossack AS/400 Software Development Comments: ----- APPNQA FORUM appended at 20:55:12 on 93/11/08 GMT (by HEFEL at RALVM6) -- Subject: AS/400 - Non-activation XID3 request Date: 11/03/93 Owner: Stephen Lubbs Compuserve? Y We are testing our APPN end node implementation against an AS400 network node. We are not able to get the AS400 to acknowledge our attempts to initiate a non-activation XID sequence over an SDLC link. The initial XIDs indicate lack of support for non-activation XIDs. - Are there specific settings on the AS400 controlling support of non-activation XIDs? - Is support of non-activation XIDs a base function for Network nodes? Can we count on it being there? - Is support of non-activation XIDs link specific in any way? - Any thoughts as to why we are having trouble with this, if the answer is covered by my other questions? FYI, we are not terrifically familiar with the AS400. You might even say we are "technically challenged" when it comes to the AS400. So it is likely that there is a simple-minded solution. Answer: AS/400 does NOT support secondary initiated non-activation XID3 just as byte 9 bit 6 indicates. It is not a configurable option. This is not a base function, but rather a product option to implement. Security(Public/Private): Public Architect: Larry Plank Comments: ----- APPNQA FORUM appended at 16:04:02 on 93/11/09 GMT (by HEFEL at RALVM6) -- Subject: APPN CP - CP Sessions Date: 11/08/93 Owner: Stephen Lubbs Compuserve? Y Question: Here's somemore questions for y'all. These are with respect to a non-ABM link, the TG to the Net Node is up, and Cp-Cp capabilities have been requested. - Will the NetNode initiate its ContWinner Cp session before the EN initiates its ContWinner Cp Session? If so, can bind be rejected by the EN without affecting underlying TGs, and assuming it can be done, what sense code should be used? - A related question: can a TG be up on which Cp capabilities were requested but over which there is no Cp-Cp sessions? I know these may sound strange, but the highly distributed nature of our environment makes these questions pertinent. Answer: - If the NN (Network Node) is downlevel (does not support function set 1015), then the NN could initiate its ConWinner CP-CP session before the EN initiates its ConWinner CP-CP session. The EN may reject the BIND by sending an UNBIND with sense data value X'08B50000'. This should not affect the underlying TG. The "SNA APPN Architecture Reference" (SC30-3422-03) has a section "End Node CP-CP Session Activation Migration Support" on pp.5-17 and 5-18 which explains the function of 1015 in an EN as well as dealing with a NN which does not implement 1015. Be sure to read that section for special considerations. - A TG can be up over which CP capabilities were requested, and no CP-CP session is currently active. However, this would result from an error situation. CP capabilities exchange is an integral part of CP-CP session activation. See the "SNA APPN Architecture Reference" (SC30-3422-03) figures 5-20, 5-21, and 5-21 for details. Security(Public/Private): Public Architect: Candace Elder Comments: ----- APPNQA FORUM appended at 19:09:57 on 93/11/10 GMT (by HEFEL at RALVM6) -- Subject: Border Node Capabilities - Extended and Peripheral Date: 10/27/93 Owner: Rainier Foeppl Compuserve? Y Question: We are just in the process of designing our network and how to migrate to APPN. It would be a great help to know what are the capabilities of the following node-types connected to a APPN and to a SNA/SNI Network. How many hops (=netids) can be crossed ? LEN into SNI NNNA or NNNC into SNI LEN into CNN (assuming Bordernode type 2 also if not available today) NNNA into CNN with bordernode type 2 As this is for designing only we can assume bordernode type 2 (extended border node) for the CNN-Nodes. The LEN-Nodes and NNNA/NNNC nodes have only bordernode Type 1 (normal border nodes) capabilities. The question is not only if you can enter the network sucessfully, but also if you can then work in it with the possiblity to cross an other network. By the way is there a manual or a set of foils that describe the capabilities of the different node-types in a multi-netid-network ? Thank you very much for your help. Rainer Answer: NETA NETB NETC NETD | | | | +--+-+ +-----+ +-------+-------+ +--+-+ | | | | | | | | +----+ +-----+ +----+ +----+ +----+ |LENa|-----|SSCPa|-----|LENb|-----|EBNa|-----|EBNb| +----+ +-----+ +----+ +----+ +----+ PLU SLU This can be made to work, with a few configuration restrictions. First, EBNa must be a VTAM. This should be no problem as VTAM is the only product to issue a Statement of Direction to implement Extended Border Node (EBN). In addition, the connection from LENb to EBNa must remain a LEN connection and not be upgraded to an APPN connection, unless LENb is also a VTAM. Your description made it sounded as though LENa and LENb were AS/400s as they were described as Peripheral Border Nodes. The reason the connection from LENb to EBNa needs to remain LEN is VTAM needs to initiate the search into the APPN network. A LEN node sends the SLU name unqualified in the BIND. VTAM will realize that the SLU NETID is unknown when it receives the BIND and will send a Locate-Find request into the APPN network to determine the location of the SLU. In the Find GDS variable, VTAM will set a field indicating the SLU NETID is unknown. Extended Border Nodes have been designed so that they understand this new field, and will change the NETID of the SLU prior to sending the request into a non-native network. The result is the search request will look for NETC.SLU in NETC and NETD.SLU in NETD. The first xxx.SLU which is found is the one the BIND will be sent to. Currently, only VTAM sets this field in the Find GDS variable. If any other product initiates the search into the APPN network, then the search will only be for NETC.SLU. One other thing as well. Since the NETIDs are being swapped, the NETIDs of the session partners will be different depending on the network in which the information is displayed. In NETA, the session partners will be displayed as NETA.PLU and NETB.SLU. In NETB, the session partners will be displayed as NETA.PLU and NETC.SLU. And in NETC and NETD, the session partners will be displayed as NETB.PLU and NETC.SLU. Security(Public/Private): Architect: Roy Brabson Comments: ----- APPNQA FORUM appended at 23:04:04 on 93/11/10 GMT (by HEFEL at RALVM6) -- Subject: Activation XID Exchange Date: 11/09/93 Owner: Bruce Smith Compuserve? Y Question: (NOTE: answer embedded in question, prefixed with '==>') I am writing the code to do the activation XID exchange. I have a question regarding how the link station role is determined. From the doc your suppose to compare the CP names of each node and whoever has the highest is primary. ==> Role is based on node ID (TGN is based on cp name) Well, if they're both LEN nodes in the same domain they should have the same CP names. ==> No. Having the same CP name is not allowed (caught before role negotiations) The FSM says use a random determination. I take this to mean I have to use the Node ID field. Do I set the random number in the ID field during the PRENEGOTIATION just in case the CP names are the same? ==> Yes, use the node ID. ==> Set random node ID only after you have determined that your ==> node ID's are equal. (Could be in your XID3(pn)) The docs also say that block ids of 0x0 and 0xFFF are special. I am unable to find where these values are set and why. Can I use ID field for the LS role determination or must the block number be between these two special values? ==> Consider the node ID as 2 parts x'xxxyyyyy'. When randomizing, ==> leave the 'xxx' unchanged and only randomize the 'yyyyy' part. Security(Public/Private): Public Architect: Jim Amundson Comments: ----- APPNQA FORUM appended at 18:13:46 on 93/12/29 GMT (by HEFEL at RALVM6) -- Subject: SSCP Take-Over with LEN nodes in Network Date: 11/11/93 Owner: Rainier Foeppl Compuserve? Y Message#: 11790 Question: We have a large VTAM - Envirionment and are currently installing VTAM 4.1 As we have more than one host, we intend to takeover the owned resources to an other host if one is failing. As two hosts always have differnt names, the CNN-resources may be owned by different hosts. We have no problems with the old SNA-Network. But what happens to LEN-Nodes, where you have to define the adjacent node-name. This name changes after a takeover-process .... What happens to APPN-Nodes ? Answer: First, let me say that this is not a VTAM V4R1 problem. This problem has existed since VTAM first supported independent LUs (VTAM V3R2 ?). The requirement to define the name of the adjacent node across a LEN link was due to the way APPN RSCVs were calculated. The last hop in the APPN RSCV had to describe the LEN link to the adjacent node and, as with all hops in the RSCV, had to include the CP name of the adjacent node. Since VTAM did NOT provide a CPname during XID3 exchange with the adjacent LEN node, the CPname of VTAM had to be predefined at the adjacent node. (Since VTAM did not support calculating RSCVs at that time, there was no need to do likewise in VTAM.) Once the RSCV was calculated, the BIND routed correctly. In fact, even when SSCP-takeover occurred and the name of the adjacent LEN node changed, this was not reflected back to the node that had the CPname predefined, but BINDs were still routed correctly. The only problem that resulted was that an incorrect CP name was provided in the RSCV. Since NetView was never provided with these RSCVs, no one really noticed that the name was incorrect. This is how it works for LEN links. And, in fact, you'll find that this is STILL how it works for LEN links, even with VTAM V4R1. Except now VTAM V4R1 WILL provide the RSCVs to NetView, for Session Awareness and session route displays. Since the CPname of VTAM can change (when SSCP takeover occurs), the NetView displays may now be slightly incorrect. With VTAM V4R1, VTAM now supports APPN-level links. APPN connectivity is much more complicated, in that LINK definitions are distributed throughout the network to every Network Node (via Topology Database Updates, or TDUs). These TDUs require a TG Number and an adjacent CPname (and the CP name must be accurate!). As a result, some new architecture was designed to allow an adjacent node to change it's CP-name without actually recycling the link. This was referred to as 'Non-Activation XID3 Exchange'. Details follow: FID4 VTAM1====+ FID2 NCP----NN VTAM2====+ FID4 Suppose VTAM1 owns the FID2 link station to NN. When the link station is activated, normal XID3 exchange occurs, and APPN TDUs are sent through the network. When VTAM1 fails, NCP1 immediately informs NN that the link is quiescing. When VTAM2 takes over this link station, several things can occur: - If VTAM2 doesn't support APPN (i.e. it is pre-VTAM V4R1), then the link remains in 'limbo'. It remains active and is still used as a LEN-level link. However, it is NOT reported as 'active' to the TDB, so APPN nodes will no longer calculate session routes over this link. - If VTAM2 suppors APPN, but the adjacent NN does not support the new 'CP name change' function of non-activation XID3 exchanges, then the same thing happens as above. I.E. the links remains in 'limbo' and can be used as a LEN link, but not as an APPN link. - If VTAM2 supports APPN and the adjacent NN supports CP-name change, then the non-activation XID3 exchanges result in the two nodes re-learning each other CP names, re-negotiating a new TG number (if necessary) and re-sending the TDUs that describe this link. Once the TDUs are distributed throughout the network, all NNs will be able to calculate routes over this link again. If VTAM1 ever takes-over this link, the same thing happens again, and the adjacent (Composite) node becomes VTAM1 again. Security(Public/Private): Public Architect: Johnathan Harter Comments: ----- APPNQA FORUM appended at 18:15:44 on 93/12/29 GMT (by HEFEL at RALVM6) -- Subject: AS/400 - Secondary Initiated XID3 Date: 11/15/93 Owner: Stephen Lubbs Compuserve? Y Message#: 11744 Question: >>>AS/400 does NOT support secondary initiated non-activation XID3 just >>>as byte 9 bit 6 indicates. It is not a configurable option. >>>This is not a base function but a product option. Does this apply to ALL links? The documentation I have at hand (SNA Type 2.1 Node Reference,SC30-3422-2) states on page 9-22 on the first line under 'Rules for Nonactivation XID Exchanges on ABM TGs' that "Link stations supporting ABM always support the secondary-initiated nonactivation exchange option." Also, the redbook titled 'APPN Architecture and Product Implementations Tutorial' states on page 39 that "... no IBM implementation of an end node actually uses the non-activatio XID to change server in the architecturally allowed way, although all implementations could receive such an XID and honor it." The first quote states flat out that at least for ABM links, nonactivatio XIDs are to be supported. The second seems to strongly imply support. Are these documentation errors or am I missing something? Neither situation would suprise me. Answer: I just talked with our XID manager guy, and for ABM links we do support receiving secondary initiated non-activation XIDs. We'll never SEND a non-activation XID of any kind. Security(Public/Private): Architect: Dennis Frett AS/400 APPN Devt. Comments: ----- APPNQA FORUM appended at 18:18:25 on 93/12/29 GMT (by HEFEL at RALVM6) -- Subject: Adaptive Pacing Date: 11/29/93 Owner: Stephen Lubbs Compuserve? Y Message#: 12147 Question: We are testing an APPN End Node implementation with an MVS host running VTAM level 3.3 (or 3.4) and a 3745 FEP running NCP level 5.4. We have connected two nodes to the FEP (referred to as NodeA and NodeB). These two nodes talk to each other using independent LU-LU sessions which are routed via the NCP. During the XID exchange we specify support for Adaptive pacing. When a BIND is sent from NodeA to NodeB, the NCP seems to always route the BIND to the other node as an 'Adaptive Pacing' BIND (Bytes 8-13 are 00 80 85 85 80 00) irrespective of whether the NodeA has sent it with Fixed Pacing or Adaptive Pacing. Later when a Pacing Indicator is received by NodeB, it sends an IPM to the FEP which causes the FEP to UNBIND the session with a sense code control vector specifying (1001 0003) which means it does not like the format of the IPM. The format of the IPM seems to be OK. The sequence of NodeA FEP NodeB ===== === ===== BIND(Fixed or Adaptive) ---> BIND (Adaptive Pacing)---> <--- +BIND (Fixed or Adaptive) <--- +BIND Rsp (Adaptive) LUSTAT ----> LUSTAT (Pacing Indicator)---> <--- IPM (Next Window = 01) UNBIND (Cleanup) ---> (Extended Sense Code = 1001 0003) <--- UNBIND (Clean Up) Why is this happening? Is it a problem with NCP or VTAM? Any ideas on how do to get around this problem? Answer: Everything seems to be in order; thus, it is not clear why the UNBIND is generated. You say the format of the IPM seems to be ok. What is the format of the IPM? The Type field should be set to 00 (solicited); the Reset Current-Window Residual-Count Indicator bit should be set to 0 (do not reset); the Next Window Size field should be in the range 1 - 32,767 (you indicate it is set to 01). The 10010003 sense data might indicate one of the following: 1. The Type field is set to 11. 2. The Type field is set to 00 (solicited), and the Reset Current-Window Residual-Count Indicator bit is set to 1 (reset). 3. The Type field is set to 00 (solicited), and the Next Window Size field is set to 0. 4. The Type field is set to 01 (unsolicited), and the Reset Current-Window Residual-Count Indicator bit is set to 0 (do not reset). Security(Public/Private): Architect: Gary Dudley Comments: ----- APPNQA FORUM appended at 14:24:27 on 94/02/09 GMT (by HEFEL at RALVM6) -- Subject: IBM-supported SAP Addresses Ref: Append at 18:13:46 on 93/12/29 GMT (by HEFEL at RALVM6) Date: 02/10/94 Owner: Burt Gearhart Compuserve? N Message#: Question: What are the currently assigned or used SAP addresses? What IBM products support configuring SSAP and DSAP values to other than X'04'? Answer: If the first question is what SAP addresses do SNA boxes use, then the answer is X'04' and multiples of it. I do not know what the upper limit is on this (04,08,12,etc.), except obviously it must fit in 1 octet. As far as the second question, I know that at least one product supports multiple logical links between the same two nodes (multiple SAP addresses) but I do not know what each product does (I am nearly positive that NCP supports multiple). You may have to survey each product. Security(Public/Private): Architect: Jim Ragsdale Comments: